モーフィング周りはかなり考えることがあって時間がかかるので、優先度的にレビューは後回し気味でも問題なさそうでしょうか…？🙇

現状のエンジン側の仕様を整理し、コアも設計から再確認していく形になりそうです。
このPRの内容はAPIに現れないと思うので、このPRだけならそこまで考えずで実装しちゃっても問題なさそうかも。

#713 は後回し（来年）でもよいです。

このPRだけならそこまで考えずで実装しちゃっても問題なさそうかも。

このPRで考えることがあるとすれば、permitted_synthesis_morphingがVVMに含まれるべきか、ということになるかと思います。

このPRの内容はAPIに現れないと思うので、

一応現れることは現れますね。supported_featuresは見えるけどpermitted_synthesis_morphingはプライベートという風にもできることはできそうではあります。

あ〜どこにどう出すか、なんで名前にするか等いったん考えたいですね…！
とりあえず0.16まで止めるか、プライベートにするかになりそうです。
でもちょっと設計からな気がするから、とめておくのが丸そうかもです🙇

プライベートにするか

SpeakerMetaからsupported_featuresという名のオブジェクトが生えている事だけ確約しつつ、その型をトップ型 (top type)にしておくのはどうでしょうか？

• Rust: serde_json::Value
• Python: object
• Java: java.lang.Object
• TS: unknown

ただしJSONからデシリアライズする時はpermitted_synthesis_morphingまでちゃんと見るようにします。

C APIから出すときとC API以外でJSONにシリアライズするときは、permitted_synthesis_morphingの中身を出す手もありますが検閲（#[serde::skip_serializing]）してもよいと思います（supported_featuresという名のフィールドごと消す）。

こうすればプライベートっぽくはなるはず。そうすれば後はVVMのmetas.jsonかmanifest.jsonに入れるかだけ考えればよいと思います。

supported_featuresという名前にするのか、そもそもどこに情報を格納するのかなどが未定だけど、何も案内せずしれっと何も入ってないプロパティを足すということですよね。

そこまでしなくても、いろいろ決まった後に追加でも良いのかも、とちょっと思いました！
あえて今実装したい理由とかはありますか？👀

議論が止まってるかも？（もうコンテキスト忘れてしまいましたが。。）

あ、気づいたのでコメントしただけで、催促じゃないです！